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REM ARKS/ARGUM ENTS 

Claims 1-33 remain pending, all of which stand rejected. 

1 Rejection of Claims 1. 3-10. 12-15. 17-24 and 26-33 Under 35 U.S.C. 103(a) 

Claims 1, 3-10, 12-15, 17-24 and 26-33 stand rejected under 35 U.S.C. 103(a) as 
being unpatentable over U.S. Patent Application Publication No. 2004/0054688 to Tran. 

With respect to claim 1 , the Examiner asserts that Tran teaches a method for 
tracking issues, wherein a log-in page is provided to log-in a user, in paragraph [0028]. 
Applicant respectfully disagrees. Tran's paragraph [0028] states, in part: 

In accordance with one embodiment of the invention, the user/customer 
14 uses a GUI to create and submit an issue report. For example, when a user 
/customer 1 4 has a problem with a component, he/she starts the program which 
may display a issue report screen. FIG. 4 schematically illustrates an example of 
a display screen 30 for submitting an issue report. As shown in FIG. 4, the 
display screen 30 may include a space for inputting the reporter's identification (a 
user name, user ID, email address, or the like) 32. . .. The reported date and 
other information may be automatically stamped to the issue report.. . . 

Nothing in Tran's above disclosure teaches, suggests or pertains to presentation 
of a "log-in page" or user log-in. In fact, nowhere does Tran mention the use of a 
"log-in page". Rather, Tran teaches that a user "starts the program" and is presented 
an "issue report screen" (and not a log-in page). Although the user may input their 
identification information as part of "submitting an issue report", the user's identification 
information is only "stamped to the issue report". Tran does not indicate that the issue 
report screen is equivalent to a "log-in page", or that the identification information input 
to the issue report screen is in any way used for "log-in" purposes. 

Also with respect to claim 1 , the Examiner asserts that Tran teaches a method 
for tracking issues, wherein a user is provided an interface page having "a configuration 
corresponding to a predetermined access level of the user, in paragraph [0033]. 
Applicant respectfully disagrees. Tran's paragraph [0033] states, in part: 
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Referring back to FIG. 2, the authorized user 18 is typically an 
administrator of the tracking system 10, and has a privileged access to the 
system 10. The authorized user 18 is not only permitted to download the 
component list from the database, but also modify the component list and upload 
the modified component list back to the database. Such a privileged access may 
require a specific authorization such as a password.. . . 

Nothing in the above excerpt teaches or suggests providing "an interface 
page" having "a configuration corresponding to a predetermined access level of 
the [authorized user 18]". And, in contrast to applicant's claim 1, where 1) a user is 
provided a "log-in page", 2) user information is received via the log-in page, and 3) the 
user is provided an interface page that "has a configuration corresponding to a 
predetermined access level of the user", Tran does not indicate that A) a user becomes 
"authorized" by logging in, or that B) a user is presented an interface page that is 
configured for a "predetermined access level" of the user. Rather, Tran appears to 
disclose a system where 1) log-in is not required, 2) a user is not associated with a 
predetermined access level, and 3) a user must supply a password to access a 
component list. 

In general, applicant notes that Tran describes a system where two types of 
users can access a component list 12 (see FIG. 1). The two types of users are 
"authorized users 18" (discussed in par. [0033]) and users/customers/submitters 14 
(discussed in par. [0028]). From a reading of paragraph [0028], it appears that a 
user/customer/submitter 14 can access the component list 12 just by starting an issue 
reporting program (and without any sort of authentication or log-in). See also, FIG. 8, 
item 210. From a reading of paragraph [0033], it appears that an "authorized user 18" 
must supply a password to access the component list 12. However, there is no 
indication, express or implied, that the authorized user 18 accesses the component list 
12 via an "interface page" or after "log-in". Another type of user is also mentioned by 
Tran. This other type of user is the responsible entity 16 (FIG. 1). Tran does not 
indicate how a responsible entity 16 gains access to an issue reporting system, 
although it appears (from FIG. 1) that a responsible entity 16 does not have access to 
the component list 12. 
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Further with respect to claim 1 , the Examiner asserts that Tran teaches a method 
for tracking issues, wherein the method comprises providing an embedded uniform 
resource locator of [an] issue record", in paragraphs [0026] and [0027]. More 
specifically, the Examiner asserts: 

. . Tran suggests providing an embedded URL of an issue record (page 2 
paragraph [0026] and [0027]). Here, the user/customer submits an issue report, 
via email or other means, to the administrator (responsible entity) therefore, it is 
suggested that an embedded URL would be in the email. Tran further suggests 
an embedded URL when in paragraph [0026] when the tracking system sends 
the user/customer back an email notification in response to being processed, that 
this would be an embedded URL.. . . 

8/16/2007 Final Office Action, p. 8. 

Applicant respectfully disagrees. To begin, applicant notes that Tran does not 
once mention a URL or an "embedded URL". And, although an email may reference a 
URL of the email sender (or email host), sending an email to a responsible entity when 
an issue or problem is reported (opened) (Tran, par. [0026]) is not equivalent to 
"providing an embedded URL of [an] issue record". Although the Examiner 
speculates that an email alerting a responsible entity of an issue may comprise an 
embedded URL of an issue record, applicant believes this speculative interpretation of 
Tran's teachings is being driven by applicant's own teachings and the benefit of 
hindsight reconstruction. Applicant refers the Examiner to paragraphs [0031]-[0032] of 
Tran's teachings, which state: 

[0031] . . The tracking system 10 may also notify the responsible entity 16 when 
an issue report is received, so that the responsible entity can access the system 
database to retrieve the issue report and perform necessary action. 
[0032] The responsible entity 16 is a person (or a group) who solves the issue 
and fixes the problem. The responsible entity 16 typically accesses the 
database containing the issue reports, opens an issue to be solved, 
performs necessary actions, and then reports the results to the system 10.. 



(Emphasis added). 
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Of note, Tran does not indicate that the responsible entity 16 receives an email 
and then clicks on or otherwise selects a URL embedded in the email to open the issue. 
Rather, Tran indicates that the responsible entity 16, receives an email, accesses the 
database containing issue reports, and then opens an issue to be solved. Applicant 
believes this suggests to (if not teaches) one of ordinary skill in the art that the email 
received by the responsible entity 16 does not contain an "embedded URL of the issue 
record". Thus, Tran's method does not contain a step of "providing an embedded 
uniform resource locator of the issue record", as recited in applicant's claim 1 . 

The Examiner also asserts that Tran teaches a providing an embedded uniform 
resource locator "of an issue record" in paragraph [0037]. However, paragraph [0037] 
only mentions a link to a "custom component list". Paragraph [0037] does not make any 
mention of a URL that links to an "issue record" or is "of an issue record". 

Claim 1 is believed to be allowable for at least the above reasons. Claims 3-10 
and 12-14 are believed to be allowable, at least, because they ultimately depend from 
claim 1. Claims 15, 17-24 and 26-33 are believed to be allowable, at least, for reasons 
similar to why claim 1 is believed to be allowable. 

2. Rejection of Claims 2, 1 1 . 1 6 and 25 Under 35 U.S.C. 1 03(a) 

Claims 2, 11, 16 and 25 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent Application Publication No. 2004/0054688 to Tran in 
view of U.S. Patent Application Publication No. 2002/0087679 to Pulley et al. 
(hereinafter "Pulley"). 

Claims 2, 11, 16 and 25 are believed to be allowable, at least, because 1) they 
ultimately depend from claim 1 or 15, 2) claims 1 and 15 are believed to be allowable for 
the reasons set forth in section 2 of these Remarks/Arguments, and 3) Pulley fails to 
teach that which is missing from Tran, as discussed in section 2 of these 
Remarks/Arguments. 
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3. Conclusion 



In light of the above Remarks/Arguments, applicant respectfully requests the 
issuance of a Notice of Allowance. 



Respectfully submitted, 
Holland & Hart, llp 




Gregory W. Osterloth 
Registration No. 36,232 
(303) 295-8205 
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